Secure device and system for issuing ic cards

ABSTRACT

A secure device capable of reducing influences by interruptions of communication with an external device and allowing a user to install a desired application program speedily and safely. Command storage section ( 106 ) of this secure device ( 100 ) stores command groups for executing card issuance. Card issuance section ( 104 ) extracts a series of card issuance commands corresponding to a function of a card to be acquired from the command group stored in command storage section ( 106 ) and writes the commands into a buffer of card management section ( 102 ), Card management section ( 102 ) executes each card issuance command written by card issuance section ( 104 ). Card issuance is completed through internal processing of secure device ( 100 ).

TECHNICAL FIELD

The present invention relates to a secure device represented by an IC(Integrated Circuit) card and an IC card issuance system made up of thesecure device and an external device represented by a portable terminalwhich is connected to and communicating with the secure device, and moreparticularly, to a secure device that performs card issuance processingby receiving an instruction from an external device connected theretoand communicating therewith and an IC card issuance system.

BACKGROUND ART

An IC card is currently becoming a focus of attention as a securedevice. There are IC cards that simply store data and ones that actuallycome with an OS (Operating System). As examples of use of an IC card,there are various types of IC cards, such as a contact type IC cardrepresented by a credit card and ETC (Electronic Toll Collection System)card, non-contact type IC card represented by a traffic system card andelectronic money card, and it is expected that the development of newapplication fields and expansion in scale of application fields will befurther promoted in the future.

On the other hand, the development of a multi-application card capableof downloading an application after card issuance is being carriedforward aiming at improving convenience for users and reducing barriersto entering into the market by new service providers of IC cards.

Furthermore, a technology for mounting a secure device such as an ICcard on a mobile device such as a portable terminal and downloading anapplication or using an application through the mobile device isproceeding toward practical utilization.

Here, the hardware configuration of an IC card will be explained usingFIG. 1. FIG. 1 is a functional block diagram about the hardware of an ICcard.

IC card 10 is provided with CPU (Central Processing Unit) 11, ROM (ReadOnly Memory) 12, volatile memory (example: RAM: Random Access Memory)13, volatile memory (example: EEPROM: Electrically Erasable ProgrammableRead Only Memory) 14 and I/O IF 15.

CPU 11 carries out operations. ROM 12 is a read-only memory which is notrewritable. The contents stored in ROM 12 are determined at the time ofmanufacturing the IC card and cannot be changed later. RAM 13 is areadable/writable memory. EEPROM 14 is designed to maintain its contentseven when power is turned off. I/O IF 15 is responsible for dataexchange between IC card 10 and the outside. A program executed by CPU11 is usually called an “application.” Codes for executing theapplication are stored in ROM 12 and EEPROM 14. When IC card 10 issubjected to encryption operation, IC card 10 is further provided withan encryption coprocessor in addition to the configuration shown in FIG.1.

Between the application installed in IC card 10 and the outside(reader), data is exchanged using, for example, an APDU (ApplicationProtocol Data Unit) which is a format defined by ISO/IEC7816-4. The APDUis made up of two components; a command message given from the reader tothe IC card and a response message returned from the IC card to thereader.

The format of an APDU command will be explained using FIG. 2. FIG. 2illustrates an example of the format of an APDU command.

APDU command 20 in FIG. 2 is made up of header 21 and body 22. Header 21is made up of a class (CLA), instruction (INS) and parameters (P1, P2).Body 22 is made up of a field length of command data (Lc: Length ofCommand Data) , data section and field length of response data (Le:Length of Expected Data) . The capacity of the APDU command 20 is 1 bytefor CLA, INS, P1, P2, Lc, Le each and 255 bytes for the data section, atotal of 261 bytes at maximum.

A scheme for creating an APDU will be explained using FIG. 3. FIG. 3 isa conceptual diagram showing a scheme to divide data and create an APDU.

As described above, the capacity of one APDU command 20 is as small as261 bytes, and therefore in order to send data that amounts to several Kbytes when downloading an application, the sending data needs to bedivided into a plurality of APDU blocks. The parameters (P1, P2) of eachAPDU block indicate a block number and whether or not there is any blockthat follows, and can thereby allow the IC card side to checkconsistency in the order of commands sent and the necessity for finalprocessing.

Furthermore, an expansion whereby Lc is expressed in 3 bytes with thefirst byte indicating 3-byte notation and second byte and third byteindicating a data length is proposed, but there are extremely fewexamples of such mounting from the standpoint of memory capacity of anIC card.

For a device having a small memory capacity such as an IC card, an inputbuffer for storing received commands generally cannot have a large size.When an explanation is made using multi-application card, a certain areais permanently designated as an input buffer and shared amongapplications, and the memory capacity secured is thereby limited. Themulti-application card updates “current AP information indicating acurrently selected application” when an application is selected, refersto the current AP information when the next command is received, and canthereby reliably pass the command to the selected application.

The application is downloaded through a card manager. The card manageris an application in the multi-application card that manages the cardand applications inside the card. “Management of card” refers to cardissuance that stores IDs and keys necessary for a card issuer to managethe card in the card and causing the card after issuance to transitionto locked state or terminated state. Furthermore, “management ofapplication” refers to downloading and deleting of the application.

Furthermore, there is recently a proposal of a device which can use alarge capacity memory from an IC chip as an IC card extended memoryprotection area (hereinafter referred to as “secure memory card”) andmeet the need for an increase in capacity of IC card application data.Since the secure memory card can be adapted to the size of a mobiledevice, there is an expectation for its development into use in EC(Electronic Commerce) services using a mobile device with the securememory card directly inserted into a slotted mobile device.

When a mobile device is used, communication is interrupted when locatedoutside a radio wave range, which results in an increase in thelikelihood of affecting the behavior of the card. Thus, whencommunication is interrupted, repetition processing such as doingdownloading over again from the beginning or performing resending inmid-flow is proposed.

An example of such an IC card application program loading technology isdisclosed in Patent Document 1. FIG. 4 is a block diagram of an IC cardapplication program loading apparatus disclosed in Patent Document 1.

In FIG. 4, host computer 30 stores an application program, appliespredetermined encryption processing (RSA: Rivest-Shamir-Adleman) to anapplication program and provides the application program as a dividedcomponent to IC card 50 through terminal apparatus 40. When thecommunication with host computer 30 is interrupted and exchange of datasuch as an application program is interrupted, IC card 50 sends aresending request for data other than the successfully received part tohost computer 30. Then, when all components are received, thesecomponents are integrated, subjected to decoding processing and errordetection processing. On the other hand, if the request is notsuccessfully received even when a resending request is sent apredetermined number of times, sending of the resending request isstopped and the data successfully received and stored so far is erased.

-   Patent Document 1: Unexamined Japanese Patent Publication No.    2003-108384

DISCLOSURE OF INVENTION Problems to Be Solved by the Invention

However, the IC card application program loading technology described inPatent Document 1 has the following problems.

First, since data necessary for downloading of an application programneeds to be repeatedly sent/received between the host computer and ICcard, there is a problem that when the communication between bothparties is interrupted for some reason, it is not possible to avoidinfluences on downloading and that the possibility of influencing thebehavior of the IC card increases. Especially, with an increasing memorycapacity of a secure device, high function applications are expected inthe future and the application itself tends to become enormous and thenumber of APDU blocks is consequently expected to increase accordingly.Such an increase in the number of APDU blocks means an increase in adownloading time and means an increase in the possibility thatcommunication may be interrupted by the time the downloading iscompleted. Furthermore, when communication is interrupted, even ifrepetition processing such as doing downloading over again from thebeginning or performing resending in mid-flow is performed, thecomplexity of the system and card processing due to repetitionprocessing such as repeated resendings caused by failures duringresending and user stress caused by an increase in the downloading timeare considered, and there is a demand for a scheme which can minimizeinfluences of communication interruption.

Second, the IC card is a passive device and has a problem that it canperform nothing more than incorporating an application program givenfrom the host computer and operating as instructed by this program. Thatis, the application itself of the IC card to be used is originallystored in an external device connected to the IC card (host computer inthis case) and therefore the range of applications that can be selectedby the user is limited and lacking in convenience in card issuance andapplication downloading.

Third, the host computer applies predetermined encryption processing tothe application program and sends it to the IC card, which results in aproblem that the IC card requires processings such as decoding andverification. As described above, the processing capacity of the IC cardis not high, and therefore a scheme capable of processing all data inthe form of plain text or reducing the number of decodings andverifications are performed while securing the conventional security isdesirable.

Fourth, there is another problem that in order to share a session keybetween the host computer and IC card when downloading an applicationprogram or issuing a card and perform encryption of APDU blocks to besent to the IC card using the session key and MAC (Message AuthenticateCode) verification, it is necessary to know the APDU blocks which areoriginal data. There are actually cases where an author of the APDUblocks and the provider who performs downloading of the applicationprogram and card issuance are separated from each other, and thereforewhen the APDU blocks include highly confidential information such aspersonal information, a scheme preventing the provider who performsdownloading of the application program and card issuance from knowingthe contents of the APDU blocks is expected.

The present invention is implemented in view of such problems and it isan object of the present invention to provide a secure device capable ofreducing influences of interruption of communication with an externaldevice and allowing a user to speedily and safely incorporate a desiredapplication program.

Means for Solving the Problem

The secure device according to the present invention adopts aconfiguration including a card issuance section that extracts a cardissuance command corresponding to a function of a card to be acquiredfrom command groups stored in an internal memory and a card managementsection that executes the card issuance command extracted by the cardissuance section.

The IC card issuance system according to the present invention is an ICcard issuance system comprising a secure device and an external devicethat communicates with this secure device, wherein the external devicecomprises a command generation section that generates a request commandfor requesting card issuance and a command sending section that sendsthe request command to the secure device, and the secure devicecomprises a card issuance section that extracts a card issuance commandcorresponding to a function of a card to be acquired from command groupsstored in an internal memory and a card management section thatexecutes, when the request command is input, the card issuance commandextracted by the card issuance section.

Advantageous Effect of the Invention

According to the present invention, it is possible to implement the highspeed of data processing between the external device and secure device(e.g., downloading of an application program and card issuance) byreducing the number of communications are carried out between theexternal device and secure device and reducing the security processingload inside the secure device while securing conventional security.Furthermore, the present invention allows the user to incorporate adesired application program into the secure device. Furthermore, it ispossible to technologically implement information protection which hasbeen implemented so far by means of contracts between a plurality ofproviders involved in downloading of application programs and cardissuance.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a functional block diagram related to hardware of an IC card;

FIG. 2 illustrates an example of the format of an APDU command;

FIG. 3 is a conceptual diagram showing a scheme of creating APDUs bydividing data;

FIG. 4 is a block diagram showing the configuration of a conventional ICcard application program loading apparatus;

FIG. 5 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 1 of the present invention;

FIG. 6 is a block diagram showing the configuration of the externaldevice in FIG. 5;

FIG. 7 is a sequence diagram showing processing by the external device,card management section and card issuance section according toEmbodiment 1 of the present invention;

FIG. 8 illustrates an example of the configuration of a simultaneouscommand;

FIG. 9 illustrates an example of the format of a self-issuance startcommand;

FIG. 10 is a flow chart showing the internal operation of the securedevice after a self-issuance start command is received until a read outof an APDU issuance command for card issuance is started;

FIG. 11 illustrates an example of a file management table;

FIG. 12 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 2 of the present invention;

FIG. 13 is a sequence diagram showing processing by the external device,card management section, card issuance section and privileged modemanagement section according to Embodiment 2 of the present invention;

FIG. 14 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 3 of the present invention;

FIG. 15 is a sequence diagram showing processing by the external device,card management section, card issuance section and privileged modemanagement section according to Embodiment 3 of the present invention;

FIG. 16(A) illustrates an example of reporting a response from the cardmanagement section to the card issuance section, FIG. 16(B) illustratesanother example of reporting a response from the card management sectionto the card issuance section;

FIG. 17 illustrates an example of a response decision table;

FIG. 18 is a flow chart showing the operation during self-issuance ofthe card issuance section according to Embodiment 3 of the presentinvention;

FIG. 19 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 4 of the present invention;

FIG. 20 illustrates input/output of the response calculation section;

FIG. 21 is a block diagram showing the configuration of the externaldevice in FIG. 19;

FIG. 22 is a flow chart showing the operation during self-issuance ofthe card issuance section according to Embodiment 4 of the presentinvention;

FIG. 23 illustrates an example of the format of a response indicatingthat self-issuance has failed;

FIG. 24 is a flow chart showing the operation of the external deviceafter receiving a response from the secure device according toEmbodiment 4 of the present invention;

FIG. 25 illustrates an example of a progress management table;

FIG. 26 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 5 of the present invention;

FIG. 27 illustrates an example of the configuration of a simultaneouscommand according to Embodiment 5 of the present invention;

FIG. 28 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 6 of the present invention;

FIG. 29 is a flow chart showing the operation of the secure deviceaccording to Embodiment 6 of the present invention;

FIG. 30 illustrates an example of the configuration of a simultaneouscommand according to Embodiment 6 of the present invention; and

FIG. 31 illustrates an example of the configuration of recoveryinformation included in the simultaneous command in FIG. 30.

BEST MODE FOR CARRYING OUT THE INVENTION

Now, embodiments of the present invention will be described in detailwith reference to the accompanying drawings. The present invention isnot limited to these embodiments and can be implemented in various modeswithin a range without departing from the essence thereof.

Furthermore, a “secure device” in a broad sense means a device ingeneral equipped with a chip having an application which has functionssuch as an authentication function, payment function and VPN (VirtualPrivate Network) or the like. The following embodiment will explain acase where a multi-application card is adopted as an example of thesecure device,

“Card issuance” means both issuance of a card itself having anapplication and downloading of an application to an issued card. Theembodiment below will explain both cases as examples of card issuance.

EMBODIMENT 1

FIG. 5 is a block diagram showing the configuration of secure device 100according to Embodiment 1 of the present invention.

In FIG. 5, secure device 100 is provided with card management section102, card issuance section 104 and command storage section 106.

Card management section 102 communicates with external device 150 whichwill be described later to send/receive various commands such as anapplication program, control signal or the like. Furthermore, cardmanagement section 102 manages the operation of secure device 100 bymaintaining IDs and keys necessary to issue cards and if required,making issued cards transit to locked state or terminated state.Furthermore, card management section 102 decides whether or not toaccept a request for direct access from external device 150 which willbe described later.

Card management section 102 has a function of managing downloading of anapplication program (card manager). More specifically, card managementsection 102 executes each card issuance command written by card issuancesection 104. Card management section 102 then sends a response which isa result showing whether or not the card issuance has been successful toexternal device 150.

Card issuance section 104 selects and extracts a series of card issuancecommands corresponding to the function of a card to be acquired fromcommand groups stored in command storage section 106. Furthermore, cardissuance section 104 copies each command from the series of cardissuance commands in an APDU buffer (not shown) of card managementsection 102 in turn.

Command storage section 106 is an internal memory for storing commandgroups to execute card issuance. Command groups stored in commandstorage section 106 may be stored (preinstalled) in secure device 100 atthe time of purchase or may be written from external device 150 andinserted (installed) after purchase. That is, it is possible to freelychange, add or delete command groups stored in command storage section106 according to the use or capacity of secure device 100. Furthermore,command storage section 106 has a secure area for storing data whichputs together APDU issuance commands which are a series of card issuancecommands written by direct access from external device 150.

Command storage section 106 can store a plurality of card issuancecommand groups corresponding to plural card functions. A series of cardissuance commands corresponding to the functions of the respective cardsare stored in a file as a simultaneous command which will be describedlater. Furthermore, the file storing this simultaneous command can beidentified by a file name and/or file ID.

Next, the configuration of the external device in FIG. 5 will beexplained using FIG. 6. FIG. 6 is a block diagram showing theconfiguration of external device 150 in FIG. 5.

In FIG. 6, external device 150 is provided with command generationsection 152, command sending section 154, response reception section 156and self-issuance management section 158.

Command generation section 152 generates various commands to beexchanged with card management section 102. Especially, commandgeneration section 152 generates a self-issuance start command which isa card issuance request to secure device 100 under the instruction ofself-issuance management section 158. The self-issuance start commandgenerated by command generation section 152 is output to card managementsection 102 through command sending section 154.

Command sending section 154 outputs the self-issuance start commandgenerated by command generation section 152 and other various commandsto card management section 102.

Response reception section 156 receives a response from card managementsection 102 indicating whether or not card issuance has been successful.The response received by response reception section 156 is output toself-issuance management section 158.

Self-issuance management section 158 controls generation and sending ofself-issuance start commands inside external device 150. Morespecifically, self-issuance management section 158 requests commandgeneration section 152 to issue a self-issuance start command.Furthermore, upon receiving a response indicating whether or not thecard issuance has been successful from response reception section 156,self-issuance management section 158 analyzes the response anddetermines the next operation of external device 150.

When, for example, self-issuance management section 158 receives aresponse that the card issuance has been successful, it outputs aninstruction for ending the processing by external device 150.Furthermore, in the case where an application program downloaded by thecard issuance cannot be used until secure device 100 is reported againthat the card issuance has been successful, self-issuance managementsection 158 requests command generation section 152 to issue a “cardusage authorization confirmation command.”

On the other hand, upon receiving a response that the card issuance hasfailed, self-issuance management section 158 instructs commandgeneration section 152 to re-generate and resend a self-issuance startcommand or stop card issuance.

The operation of secure device 100 configured as shown above will beexplained in detail using FIG. 7.

FIG. 7 is a sequence diagram showing processing by external device 150,card management section 102 and card issuance section 104 according toEmbodiment 1 of the present invention. The example in FIG. 7 shows acase where an APDU issuance command which has been written from externaldevice 150 is processed to download an application program.

In step S1000, an application to be used between external device 150 andcard management section 102 is selected. More specifically, externaldevice 150 sends a command to select a card manager (=application usedfor card issuance) to card management section 102. Next, when cardmanagement section 102 receives a command from external device 150 andsuccessfully selects a card manager, “current AP information” indicatingan AP currently selected is updated in card management section 102 andupon receiving the next command, the updated “current AP information” isreferred to. In this way, the next command can be passed to cardmanagement section 102.

In step S1100, mutual authentication processing is performed betweenexternal device 150 and card management section 102. More specifically,one or both external authentication whereby secure device 100authenticates external device 150 and internal authentication wherebyexternal device 150 authenticates secure device 100 is/are performedaccording to the required security level.

It should be noted that the authentication step in step S1100 ispreferably performed when writing highly confidential data, but it canbe omitted when writing other data.

In step S1200, external device 150 performs direct access processing towrite data which puts together APDU issuance commands for executingdownloading of an application program (hereinafter referred to as“simultaneous command”) 160 into the secure area of command storagesection 106. Simultaneous command 160 written through direct access asdescribed above is saved in a file so as to be identifiable with a filename and file ID and stored in command storage section 106.

At this time, external device 150 cannot read out nor write in commandsstored in command storage section 106 unless it is authorized to do soby the application selected in step S1000. Since direct access uses ablock transimit protocol which allows writing of several mega bytes dataat a time, simultaneous command 160 for downloading the applicationprogram can be sent by way of only one time direct access.

Here, simultaneous command 160 will be explained using FIG. 8. FIG. 8illustrates an example of the configuration of simultaneous command 160.

In FIG. 8, simultaneous command 160 is made up of APDU number 161indicating the number of APDU issuance commands which make upsimultaneous command 160 and command entity 162. In the example of FIG.8, APDU number 161 is m.

Command entity 162 is made up of data consisting of APDU issuancecommands 165-1, 165-2, 165-3, . . . , 165-m and command lengths 170-1,170-2, 170-3, . . . , 170-m indicating with how many bytes each APDUissuance command is formed.

In step S1300, external device 150 sends self-issuance start command 180which is a card issuance request to secure device 100 to card managementsection 102. This self-issuance start command 180 is generated bycommand generation section 152 which has received the issuance requestfrom self-issuance management section 158 and sent through commandsending section 154.

“Self-issuance” in the present specification means performing processingeach APDU issuance command making up simultaneous command 160 stored incommand storage section 106 between card management section 102 and cardissuance section 104 and carrying out card issuance. The operations ofcard management section 102 and card issuance section 104 duringself-issuance will be explained in detail in posterior step S1500-1 tostep S1500-m.

Here, self-issuance start command 180 will be explained using FIG. 9.FIG. 9 illustrates an example of the format of self-issuance startcommand 180.

In FIG. 9, self-issuance start command 180 is made up of header section181 to identify a self-issuance start command, file identificationinformation 182, offset 183 and length 184.

File identification information 182 is information to identify a filewhich saves simultaneous command 160 (e.g., file name and file ID).Offset 183 is information which indicates a read out position in theidentified file and length 184 is information which indicates the lengthof data to be read out.

When default processing is possible for such reasons that a file whichsaves simultaneous command 160 is uniquely defined, the file name andfile ID or the like of file identification information 182 need not tobe included.

Card management section 102 cannot receive the next command unless itsends a response after receiving self-issuance command 180. In stepS1400, card management section 102 receives self-issuance start command180 sent in S1300 and outputs a self-issuance trigger to card issuancesection 104 as a response to self-issuance start command 180. Theself-issuance trigger includes the address of simultaneous command 160,offset 183 and length 184. This self-issuance trigger becomes a triggerto start self-issuance for card issuance section 104. That is,sending/reception of the self-issuance trigger causes processing on eachAPDU issuance command making up simultaneous command 160 to be startedbetween card management section 102 and card issuance section 104.

In step S1500-1 to step S1500-m, processing on each APDU issuancecommand making up simultaneous command 160 (self-issuance) is performedbetween card management section 102 and card issuance section 104.

First, when card issuance section 104 receives the self-issuance triggerfrom card management section 102, it extracts first APDU issuancecommand 165-1 (e.g.: Install For Load) specified by command length 170-1of simultaneous command 160 shown in FIG. 8 and copies it to APDU buffer(not shown) inside card management section 102. At this time, cardissuance section 104 increments the “number of preceding commands”managed in card issuance section 104 by 1. The “number of precedingcommands” indicates the number of APDU issuance commands making upsimultaneous command 160 which have been processed successfully andneeds to be set to zero when the self-issuance trigger from cardmanagement section 102 is received. The number of preceding commands isstored in a non-volatile storage area such as EEPROM (not shown).

Card management section 102 executes APDU issuance command 165-1(Install For Load) copied into the APDU buffer and outputs a status word(e.g. 9000h) indicating the successful end as its response to cardissuance section 104 (S1500-1) in the case of a successful end.

Next, upon confirming that the status word from card management section102 indicates a successful end, card issuance section 104 extracts thenext APDU issuance command 165-2 (e.g.: Load1) from simultaneous command160 and copies the next APDU issuance command 165-2 to the APDU bufferin card management section 102. Then, card management section 102executes APDU issuance command 165-2 (Load1) copied into the APDU bufferand outputs a status word indicating a successful end as its response tocard issuance section 104 (S1500-2) in the case of a successful end.

When card issuance section 104 copies the APDU issuance command to theAPDU buffer, it is preferable to delete the APDU issuance commandpreviously executed by card management section 102.

Hereinafter, card management section 102 likewise executes APDU issuancecommands 165-3 to 165-m making up simultaneous command 160 copied intothe APDU buffer by card issuance section 104. That is, the APDU issuancecommand is repeatedly executed until the “number of preceding commands”managed by card issuance section 104 matches APDU number 161 (S1500-3 toS1500-m).

When an error such as a memory shortage occurs in mid-flow of theprocessing on the APDU issuance command, card issuance section 104outputs a status word (e.g.: 6A84h) indicating an unsuccessful end tocard management section 102 and stops the processing on the APDUissuance command at that time.

In step S1600, card management section 102 sends a response indicatingwhether or not executions of all APDU issuance commands have beensuccessfully completed, that is, whether or not the card issuance hasbeen successful to response reception section 156 of external device150. More specifically, card management section 102 sends a status wordindicating a successful end (e.g.: 9000h) when the card issuance hasbeen successful and status word indicating an unsuccessful end (e.g.:6A84h) when the card issuance has failed to response reception section156 of external device 150.

Self-issuance management section 158 of external device 150 analyzes theresponse indicating whether or not the card issuance from cardmanagement section 102 received by response reception section 156 hasbeen successful and determines the next operation of external device150.

If, for example, the response indicate that the card issuance has beensuccessful, self-issuance management section 158 issues an instructionthat the processing by external device 150 should be ended and externaldevice 150 ends the processing. Furthermore, when the downloadapplication program cannot be used until secure device 100 is reportedagain that the response indicating the success of the card issuance hasbeen confirmed, self-issuance management section 158 requests commandgeneration section 152 to issue a “card usage authorization confirmationcommand.” In this case, external device 150 ends the processing afterthe “card usage authorization confirmation command” generated by commandgeneration section 152 is reported to secure device 100 through commandsending section 154.

On the other hand, if the response indicate that the card issuance hasfailed, self-issuance management section 158 outputs an instruction forregenerating and resending self-issuance start command 180 to commandgeneration section 152 and restarts the processing from step S1300 inFIG. 7. Furthermore, when self-issuance management section 158 receivesa response that the card issuance has failed even if card issuanceprocessing has been attempted for predetermined times, self-issuancemanagement section 158 may output an instruction for stopping the cardissuance to command generation section 152 and external device 150 mayend the processing. At this time, the number of card issuanceprocessings to be attempted is arbitrary.

As described above, the communication carried out between externaldevice 150 and secure device 100 for card issuance is only writing ofsimultaneous command 160 by direct access and sending/reception ofself-issuance start command 180 which is a card issuance request. Thatis, the card issuance processing after receiving self-issuance startcommand 180 is completed with the internal processing on secure device100 by repeating processing on the APDU issuance command between cardmanagement section 102 and card issuance section 104 as shown in theabove step S1500-1 to step S1500-m.

Here, the operation inside secure device 100 after self-issuance startcommand 180 is received until a read out of an APDU issuance command forcard issuance is started will be explained using a flow chart in FIG.10.

First, in step S2000, card management section 102 analyzes headersection 181 of the received command and confirms that self-issuancestart command 180 has been received.

In step S2100, card management section 102 identifies the addresscorresponding to file identification information 182 with reference tofile management table 190 (which will be described later) stored in cardmanagement section 102. That is, card management section 102 identifiesthe file stored in the secure area inside command storage section 106.

FIG. 11 illustrates an example of the file management table. Filemanagement table 190 describes, for example, a file name, file path,file identification information, file size, accessibility flag whichindicates whether direct access is possible or not and address, and therespective contents are added when a file is created.

Next, in step S2200, card management section 102 outputs a self-issuancetrigger to card issuance section 104. The self-issuance trigger includesthe address of simultaneous command 160, offset 183 and length 184.

Next, in step S2300, card issuance section 104 identifies the physicalreading out position of the first APDU issuance command from the addressof simultaneous command 160 and offset 183 included in the self-issuancetrigger.

In step S2400, each APDU issuance command making up simultaneous command160 is read out and executed between card management section 102 andcard issuance section 104, that is, self-issuance is started. Here, thelength of readable simultaneous command 160 must be smaller than readoutlength 184 included in self-issuance start command 180.

In this way, inside secure device 100, reading out of the APDU issuancecommand is started after card management section 102 receives theself-issuance command from external device 150.

This embodiment has explained the case where card issuance is performedby executing an APDU issuance command making up simultaneous command 160written by direct access from external device 150, but the presentinvention is not limited to this. For example, when the APDU issuancecommand corresponding to the function of a card to be acquired is storedin command storage section 106 beforehand, it is possible to completecard issuance inside secure device 100 without carrying out anycommunication between external device 150 and secure device 100.

In this way, according to this embodiment, downloading of an applicationand card issuance processing are completed inside the secure device, andtherefore it is possible to reduce the number of times communicationsbetween the external device and secure device are carried out, reduceinfluences by interruption of communication and improve safety of cardissuance.

That is, conventionally, the number of communications between theexternal device and secure device in card issuance includes several toseveral ten times in proportion to the size of an application duringdownloading of the application, but in this embodiment, the number ofcommunications can be reduced to one time of direct access and one timeof self-issuance command. As a result, the exchange of a card issuancecommand which would be conventionally performed between the externaldevice and card management section can be performed inside the securedevice according to this embodiment, and can thereby drastically reducethe risk of communication interruption often occurred in case of amobile network.

Furthermore, during downloading of an application according to aconventional technology, a session key is shared between the externaldevice and secure device at the time of authentication, then theexternal device performs encrypting and MAC assignment to the APDUissuance command and the secure device performs decrypting and MACverification on the APDU issuance command from the external device.

In contrast, in this embodiment, both sides are mutually authenticatedthrough external authentication and internal authentication, then asimultaneous command is stored in an area only accessible to the cardmanagement section by direct access and download processing is completedinside the secure device having tampering resistance using thissimultaneous command inside the secure device without exposing data tothe outside. Therefore, this embodiment need not take eavesdropping ortampering into consideration at the time of card issuance, and thereforeencryption and MAC assignment are not necessary. As a result, the cardmanagement section only needs to process plain text, and the speed ofdownload processing therefore increases.

Furthermore, since an overall length of a transmittable APDU issuancecommand is fixed, the size of data transmittable with one APDU issuancecommand in the case of plain text is larger compared to when encryptionor MAC assignment is performed. Therefore, when plain text processing isapplicable, the total number of commands issued is also small and speedenhancement of download processing is also effective in this respect,too.

Furthermore, according to this embodiment, it is possible to freelychange, add or delete command groups stored in the command storagesection and a simultaneous command written into the secure area of thecommand storage section, and thereby implement a secure device having anapplication requested by the user.

Furthermore, according to this embodiment, when the provider whoprovides card issuance data is different from the operater who operatescard issuance, card issuance is completed without the operate's knowingwhat commands are set in advance by the provider, and therefore it ispossible to realize security protection at the time of card issuance.

EMBODIMENT 2

FIG. 12 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 2 of the present invention. The same componentsas those in the secure device according to Embodiment 1 are assigned thesame reference numerals and explanations thereof will be omitted.

In FIG. 12, secure device 200 adopts a configuration corresponding tosecure device 100 in FIG. 5 further provided with privileged modemanagement section 202.

Privileged mode management section 202 operates in coordination withcard management section 102 and card issuance section 104 and sets amode called a “privileged mode” in secure device 200.

The “privileged mode” is a mode in which top priority is given to cardissuance processing inside secure device 200, that is, processing of anAPDU issuance command making up simultaneous command 160 between cardmanagement section 102 and card issuance section 104 (self-issuance). Aslong as a privileged mode is set, data cannot be exchanged with externaldevice 150 through a contact interface or non-contact interface ofsecure device 200 (e.g., sending/reception of self-issuance startcommand and response). Timing at which privileged mode managementsection 202 sets a privileged mode will be explained in detail in thelater explanation of the operation.

The operation of secure device 200 configured as described above will beexplained in detail using FIG. 13.

FIG. 13 is a sequence diagram showing processing by external device 150,card management section 102, card issuance section 104 and privilegedmode management section 202 according to Embodiment 2 of the presentinvention.

Processes in step S3000 to step S3400 in FIG. 13 and process in stepS3700 are the same as the processes in step S1000 to step S1400 in FIG.7 and process in step S1600, and therefore explanations thereof will beomitted.

In step S3500, after card issuance section 104 receives a self-issuancetrigger from card management section 102, privileged mode managementsection 202 sets a privileged mode in secure device 200. Morespecifically, card issuance section 104 that has inputted aself-issuance trigger from card management section 102 instructsprivileged mode management section 202 to set a privileged mode orinstructs privileged mode management section 202 to set a privilegedmode at the same time as card management section 102 outputs theself-issuance trigger to card issuance section 104. Then, privilegedmode management section 202 receives an instruction from card managementsection 102 or card issuance section 104 and sets the privileged mode insecure device 200.

Note that the privileged mode need not always be set after card issuancesection 104 receives the self-issuance trigger. For example, theprivileged mode may also be set after a lapse of a predetermined periodafter card management section 102 receives a self-issuance start commandfrom external device 150 or card issuance section 104 receives aself-issuance trigger.

In step S3600-1 to step S3600-m as in the case of step S1500-1 to stepS1500-m in FIG. 7, self-issuance is performed between card managementsection 102 and card issuance section 104. At this time, a privilegedmode is set in secure device 200, and therefore data cannot be exchangedbetween secure device 200 and external device 150 even through thecontact interface and non-contact interface in secure device 200.

After the privileged mode is set once and secure device 200 hastransitioned to a privileged mode, the privileged mode is canceled bypower supply halting to secure device 200, selection of anotherapplication or re-selection of currently selected card managementsection 102.

In this way, this embodiment sets a privileged mode in the securedevice, prevents data from being exchanged between the secure device andexternal device for a period which the privileged mode is set, and canthereby safely and reliably perform card issuance processing inside thesecure device without any interference.

EMBODIMENT 3

FIG. 14 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 3 of the present invention. The same componentsas those in the secure device according to Embodiment 2 are assigned thesame reference numerals and explanations thereof will be omitted.

Comparing with secure device 200 in FIG. 12, in FIG. 14, secure device300 adopts a configuration having card issuance section 302 andprivileged mode management section 304 instead of card issuance section102 and privileged mode management section 202.

Card issuance section 302 is provided with response decision table 306to decide whether or not a status word from card management section 102after processing of each APDU issuance command during card self-issuancemeans successful.

Card issuance section 302 has the following function in addition to thefunction of card issuance section 102. That is, card issuance section302 refers to response decision table 306 to decide whether or not eachAPDU issuance command has been executed successfully by card managementsection 102 during self-issuance, that is, whether or not self-issuancehas been successfully performed. When the decision result shows thatself-issuance has been successfully completed or that some APDU issuancecommands have not been executed successfully during self-issuance, cardissuance section 302 outputs the decision result to privileged modemanagement section 304.

In addition to the function of privileged mode management section 202,after a privileged mode is set in secure device 300, privileged modemanagement section 304 has a function of canceling the set privilegedmode when any one of a decision result that self-issuance has beensuccessfully completed or a decision result that self-issuance has notbeen executed successfully is input from card issuance section 302.

The operation of secure device 300 configured as shown above will beexplained in detail using FIG. 15.

FIG. 15 is a sequence diagram showing processing by external device 150,card management section 102, card issuance section 302 and privilegedmode management section 304 according to Embodiment 3 of the presentinvention.

Processes in step S4000 to step S4500 in FIG. 15 are the same as theprocesses in step S3000 to step S3500 in FIG. 13, and thereforeexplanations thereof will be omitted.

In step S4600-1 to step S4600-m, self-issuance is performed between cardmanagement section 102 and card issuance section 302. At this time,since a privileged mode is set in secure device 300, data cannot beexchanged between secure device 300 and external device 150 even throughthe contact interface and non-contact interface of secure device 300.

First, upon inputting a self-issuance trigger from card managementsection 102, card issuance section 302 extracts first APDU issuancecommand 165-1 (e.g.: Install For Load) specified by command length 170-1of simultaneous command 160 shown in FIG. 8 and copies first APDUissuance command 165-1 to an APDU buffer in card management section 102.

Card management section 102 executes APDU issuance command 165-1(Install For Load) copied into the APDU buffer. Card management section102 reports a status word indicating a successful end as its responsewhen the execution is successfully completed, and reports a status wordindicating an unsuccessful end as its response when the execution is notsuccessfully completed to card issuance section 302 (S4600-1).

Here, the method of reporting a response from card management section102 to card issuance section 302 will be explained using FIGS. 16(A),(B). FIG. 16(A) illustrates an example where card management section 102reports a response to card issuance section 302. FIG. 16(B) illustratesanother example where card management section 102 reports a response tocard issuance section 302.

In the example of FIG. 16(A), a response is reported by copying responsedata stored in the response buffer of card management section 102 intothe response buffer of card issuance section 302. On the other hand, inthe example in FIG. 16(B), a response is reported by card issuancesection 302 which referes to response data stored in the response bufferof card management section 102.

With reference to response decision table 306, card issuance section 302decides whether or not APDU issuance command 165-1 (Install For Load)has been processed successfully by comparing the status word which is aresponse from card management section 102 with response decision table306.

When the decision result shows that APDU issuance command 165-1 has beenprocessed successfully, card issuance section 302 moves to the nextprocessing on APDU issuance command 165-2 (Load1). Furthermore, when thedecision shows that APDU issuance command 165-1 has not been processedsuccessfully, card issuance section 302 sends its decision result toprivileged mode management section 304 and requests a cancellation ofthe privileged mode.

Upon receiving the decision result that APDU issuance command 165-1 hasnot been processed successfully and the privileged mode cancellationrequest from card issuance section 302, privileged mode managementsection 304 cancels the privileged mode set in secure device 300. Afterthe cancellation of the privileged mode, communication with externaldevice 150 becomes possible and card management section 102 sends astatus word meaning that card issuance has failed (e.g.: 6A84h) toresponse reception section 156 of external device 150.

Here, response decision table 306 will be explained using FIG. 17. FIG.17 illustrates an example of response decision table 306.

In the example of FIG. 17, response decision table 306 shows that thestatus word of the reported response being “9000h” means that the APDUissuance command has been processed successfully (success) and thestatus word of the reported response being “other than 9000h” means thatthe APDU issuance command has not been processed successfully (failure).

Hereinafter, self-issuance is likewise performed by sequentiallyprocessing respective APDU issuance commands 165-2 to 165-m making upsimultaneous command 160 between card management section 102 and cardissuance section 302.

When some APDU issuance command is not processed successfully duringself-issuance, the privileged mode is canceled. In this case, cardmanagement section 102 sends a status word meaning that card issuancehas failed to response reception section 156 of external device 150(S4800).

On the other hand, even when all APDU issuance commands 165-1 to 165-mhave been processed successfully and self-issuance has been successful,the privileged mode is also canceled. In this case, card managementsection 102 sends a status word meaning that card issuance has beensuccessful to response reception section 156 of external device 150(S4800).

Next, the operation of card issuance section 302 according to thisembodiment after self-issuance starts will be explained using FIG. 18.

FIG. 18 is a flow chart showing the operation of card issuance section302 according to Embodiment 3 of the present invention duringself-issuance. This embodiment will be explained assuming that aprivileged mode is set in secure device 300.

First, in step S5000, card issuance section 302 is ready for a responseanalysis and is waiting for a response indicating the processing resultof the APDU issuance command from card management section 102.

In step S5100, card issuance section 302 receives a report of theresponse indicating the processing result of the APDU issuance commandfrom card management section 102.

In step S5200, with reference to response decision table 306, cardissuance section 302 decides whether or not the response reported instep S5100 means that the APDU issuance command processing has beensuccessful As a result of the decision, when the response means success(S5200: YES), card issuance section 302 moves to step S5300 and when theresponse does not mean success (S5200: NO), card issuance section 302moves to step S5400.

In step S5300, card issuance section 302 decides whether or notprocessing on all APDU issuance commands has been completed. When thedecision result shows that the processing on all APDU issuance commandshas been completed (S5300: YES), card issuance section 302 moves to stepS5400 and when the decision result shows that the processing on all APDUissuance commands has not been completed (S5300: NO), card issuancesection 302 moves back to step S5000 and waits for a response indicatingthe processing result of the next APDU issuance command.

In step S5400, card issuance section 302 sends the information that someAPDU issuance commands have not been processed successfully or theprocessing on all APDU issuance commands has been completed toprivileged mode management section 304 and requests a cancellation ofthe privileged mode which has been set.

Thus, according to this embodiment, the privileged mode is canceled attiming at which all APDU issuance commands are processed andself-issuance is performed successfully or at timing at which some APDUissuance command is not processed successfully and self-issuance fails,and therefore it is possible to speedily report the self-issuanceprocessing result to the external device.

EMBODIMENT 4

FIG. 19 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 4 of the present invention. The same componentsas those of the secure device according to Embodiment 1 are assigned thesame reference numerals and explanations thereof will be omitted.

Comparing with secure device 100 in FIG. 5, in FIG. 19, secure device400 adopts a configuration having card issuance section 402 instead ofcard issuance section 104.

Card issuance section 402 is provided with response calculation section404 that calculates, when a failure of card issuance is detected duringself-issuance, a response including information that card issuance hasfailed and information indicating “to what extent self-issuance has beensuccessful.”

Card issuance section 402 has the following function in addition to thefunction of card issuance section 104 That is, card issuance section 402monitors a progress status of processing of each APDU issuance commandduring self-issuance and sends, when some APDU issuance command is notexecuted successfully and self-issuance fails, a status word meaningthat card issuance has failed due to an unsuccessful end and informationindicating “to what extent self-issuance has been successful” to cardmanagement section 102.

The information indicating “to what extent self-issuance has beensuccessful” includes various types of information such as the number ofsuccessfully processed APDU issuance commands, header sections of theAPDU issuance commands whose processing has failed and the number ofremaining APDU issuance commands. That is, the information indicating“to what extent self-issuance has been successful” is the informationfrom which information that identifies successfully executed cardissuance commands can be obtained.

This embodiment will explain a case where the number of successfullyprocessed APDU issuance commands is used as an example of informationindicating “to what extent self-issuance has been successful” and theinformation that identifies card issuance commands that have beenexecuted successfully is obtained from this information.

That is, response calculation section 404 according to this embodimentcalculates, when self-issuance fails, a response including informationindicating “to what extent self-issuance has been successful” using thenumber of APDU issuance commands that have been processed successfullyby then.

Calculations of response by response calculation section 404 will beexplained using FIG. 20. FIG. 20 illustrates input/output of responsecalculation section 404.

In FIG. 20, upon receiving a response that an APDU issuance command hasbeen executed successfully from card management section 102, responsecalculation section 404 increments the “number of preceding commands”managed by card issuance section 402 by 1 and moves to processing on thenext APDU issuance command. Furthermore, since the “number of precedingcommands” at the start of self-issuance is zero, the “number ofpreceding commands”, when an APDU issuance command is not executedsuccessfully and self-issuance fails, is the value indicating the numberof APDU issuance commands processed successfully by that time point.Therefore, it is possible to include information indicating thatself-issuance has failed and also the number of APDU issuance commandsprocessed successfully by the time point at which self-issuance fails,that is, information indicating “to what extent self-issuance has beensuccessful” in the response to external device 150.

Next, the configuration of external device 450 in FIG. 19 will beexplained using FIG. 21. FIG. 21 is a block diagram showing theconfiguration of external device 450 in FIG. 19.

Comparing with external device 150 in FIG. 6, in FIG. 21, externaldevice 450 is provided with self-issuance management section 452 insteadof self-issuance management section 158.

Self-issuance management section 452 is provided with progressmanagement table 454 which stores each APDU issuance command processedduring self-issuance in correspondence with contents of processing oneach APDU issuance command.

In addition to the function of self-issuance management section 158,upon receiving a response that self-issuance has failed, self-issuancemanagement section 452 has a function of identifying APDU issuancecommands which have not been executed successfully and issuing aninstruction for starting processing on the APDU issuance command.

Hereinafter, the operation of card issuance section 402 according tothis embodiment after starting self-issuance will be explained using aflow chart in FIG. 22.

First, in step S6000, card issuance section 402 is ready for a responseanalysis and is waiting for a response indicating the result of APDUissuance command processing from card management section 102.

In step S6100, card issuance section 402 receives a response reportindicating the result of the APDU issuance command processing from cardmanagement section 102.

In step S6200, card issuance section 402 decides whether or not theresponse reported in step S6100 means success of the APDU issuancecommand processing. Card issuance section 402 moves to step S6300 whenthe decision result shows that the response means success (S6200: YES)and moves to step S6500 when the response does not mean success (S6200:NO).

In step S6300, card issuance section 402 decides whether or notprocessing on all APDU issuance commands has been completed. When thedecision result shows that the processing on all APDU issuance commandshas been completed (S6300: YES), card issuance section 402 moves to stepS6400 and when the decision result shows that the processing on all APDUissuance commands has not been completed (S6300: NO), card issuancesection 402 moves back to step S6000 and waits for a response indicatingthe processing result of the next APDU issuance command.

In step S6400, card issuance section 402 generates a response indicatingthat the processing on all APDU issuance commands has been completed andself-issuance has been successful.

On the other hand, in step S6500, card issuance section 402 generates aresponse indicating that some APDU issuance commands have not beenprocessed successfully and self-issuance has failed. This responseincludes the number of preceding commands by the time self-issuancefails, that is, the number of APDU issuance commands processedsuccessfully by the time self-issuance fails.

Here, a response generated in step S6500 will be explained using FIG.23. FIG. 23 illustrates an example of the format of a responseindicating that self-issuance has failed.

In FIG. 23, response 410 is made up of the number of preceding commands411 indicating the progress status of self-issuance processing andstatus word 412 indicating that self-issuance processing has failed.

As the response format, for example, one using any bit of a 2-bytestatus word (e.g.: 63CXh (X: number of preceding commands)) may also beused in addition to the format shown in FIG. 23.

In step S6600, card issuance section 402 outputs the response generatedin step S6400 or step S6500 to card management section 102. Thisresponse is sent from card management section 102 to response receptionsection 156 of external device 450.

Next, the operation of external device 450 after receiving a responseindicating whether or not self-issuance from secure device 400 has beensuccessful will be explained using a flow chart in FIG. 24.

First, in step S7000, response reception section 156 receives a responseindicating whether or not self-issuance from card management section 102has been successful. The received response is output to self-issuancemanagement section 452.

In step S7100, self-issuance management section 452 decides whether ornot the response received in step S7000 means that self-issuance hasbeen successful. More specifically, this decision is made byself-issuance management section 452 which referes to the status wordincluded in the response.

When the result of the decision made by self-issuance management section452 shows that the response means that self-issuance has been successful(S7100: YES) , the processing by external device 450 ends. At this time,if the downloadedapplicationprogram cannot be used until the receipt ofthe response meaning that self-issuance has been successful is reportedto secure device 400 again, external device 450 generates a “card usageauthorization confirmation command”, sends the command to secure device400 and ends the processing. On the other hand, when self-issuancemanagement section 452 decides that the response does not mean successof self-issuance (S7100: NO), self-issuance management section 452 movesto step S7200.

In step S7200, self-issuance management section 452 decides whether ornot to resend a self-issuance start command. As a result of thedecision, the self-issuance management section 452 moves to step S7300when it is decided not to resend the self-issuance start command (S7200:NO), and moves to step S7400 when it is decided to resend theself-issuance start command (S7200: YES).

When secure device 400 cannot make any recovery for some reasons (e.g. ,the memory in secure device 400 is corrupted), self-issuance managementsection 452 performs nothing in step S7200.

In step S7300, with reference to progress management table 454,self-issuance management section 452 generates a “clear command” toclear data written during self-issuance (successfully processed APDUissuance command), sends the clear command to secure device 400 and endsthe processing.

Here, progress management table 454 will be explained using FIG. 25.FIG. 25 illustrates an example of progress management table 454.

Progress management table 454 describes the “number of precedingcommands” included in the response from secure device 400 and processingcontents of external device 450 corresponding to the “number ofpreceding commands” for each “number of preceding commands.”

FIG. 25 shows that an nth APDU issuance command has not been processedsuccessfully through self-issuance in secure device 400. Here, n is aninteger that satisfies 1≦n≦m (m: number of APDU issuance commands). Inthis case, in step S7300, a clear command to clear commands up to thenth successfully processed APDU issuance command (all data writtenduring issuance) is sent.

Furthermore, in step S7400, self-issuance management section 452identifies APDU issuance commands which have not been processedsuccessfully with reference to progress management table 454, resends aself-issuance start command for starting processing on the APDU issuancecommands and ends the processing.

In the example of FIG. 25, since the nth APDU issuance command has notbeen processed successfully, a self-issuance start command for startingprocessing from the nth APDU issuance command is resent.

When secure device 400 cannot start processing from the APDU issuancecommand which has not been processed successfully for reasons related tothe mounting or the like even when the above described self-issuancecommand is received, a self-issuance start command for starting cardissuance from the beginning is resent.

Thus, according to this embodiment, even when self-issuance fails, aprogress status of self-issuance indicating to what extent self-issuancehas been successful is reported to the external device, and thereforethe external device can resend a self-issuance start command forstarting processing from the APDU issuance command which has not beenprocessed successfully and thereby omit redundant, useless self-issuanceprocessing.

EMBODIMENT 5

The foregoing embodiments (Embodiments 1 to 4) have explained the methodwhereby the card issuance section which has received a self-issuancestart command identifies a file for storing a simultaneous command,extracts an APDU issuance command included in the file, copies the APDUissuance command to the APDU buffer in card management section 102 andthe card management section thereby executes the APDU issuance commandwithout distinguishing whether the APDU issuance command has been sentfrom the external device through a contact interface or non-contactinterface or is derived from self-issuance.

This embodiment will explain a mode in which an APDU buffer when acontact interface or non-contact interface is used and an APDU buffer atthe time self-issuance are not shared.

FIG. 26 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 5 of the present invention. The same componentsas those in the secure device according to Embodiment 1 are assigned thesame reference numerals and explanations thereof will be omitted.

Comparing with the secure device in FIG. 5, in FIG. 26, secure device500 adopts a configuration having card management section 502, cardissuance section 504 and command storage section 506 instead of cardmanagement section 102, card issuance section 104 and command storagesection 106.

Card management section 502 is provided with APDU buffer 508 that storesAPDU issuance commands for executing card issuance written from externaldevice 150 using a contact interface and non-contact interface.

Card issuance section 504 is provided with direct reference section 510.The card management section 502 can directly refer to an area specifiedby APDU buffer for simultaneous command 512 by way of the directreference section 510. APDU buffer for simultaneous command 512 will bedescribed later.

Command storage section 506 is provided with APDU buffer forsimultaneous command 512 that specifies part of the area of the storedsimultaneous command as an APDU buffer for the simultaneous command.

First, simultaneous command 520 in this embodiment will be explainedusing FIG. 27. FIG. 27 illustrates an example of the configuration ofsimultaneous command 520 according to Embodiment 5 of the presentinvention. FIG. 27 is an example of the configuration of a simultaneouscommand when a first APDU issuance command (Install For Load) isprocessed.

In FIG. 27, simultaneous command 520 is constructed of APDU number 521and command entity 522. APDU number 521 indicates the number of APDUissuance commands. In the example of FIG. 27, APDU number 521 is 2.

Command entity 522 is constructed of data made up of APDU issuancecommands (1-a) 525-1, (2-a) 525-2 and command lengths 530-1, 530-2indicating of how many bytes each APDU issuance command is composed.Their respective roles will be described later.

Hereinafter, the operation of secure device 500 configured as shownabove will be explained.

First, external device 150 writes an APDU issuance command for executingcard issuance into APDU buffer 508 of card management section 502.

Next, upon receiving a self-issuance start command from external device150, card management section 502 outputs a self-issuance trigger to cardissuance section 504. This self-issuance trigger is a trigger to startself-issuance for card issuance section 504.

When the self-issuance trigger from card management section 502 isinputted, card issuance section 504 extracts first APDU issuance command(e.g.: Install For Load) 525-1 from simultaneous command 520 by thelength, for example, specified by command length 530-1 in FIG. 27 andspecifies an area corresponding to the length of this APDU issuancecommand as an APDU buffer in command storage section 506.

At this time, APDU buffer 508 storing APDU issuance commands fromexternal device 150 and APDU buffer for simultaneous command 512 coexistin secure device 500. That is, the APDU buffer storing APDU issuancecommands from external device 150 belongs to card management section 502and APDU buffer for simultaneous command 512 belongs to command storagesection 506.

In the example of FIG. 27, when first APDU issuance command (1-a) 525-1is processed, the area occupied by APDU issuance command (1-a) 525-1(specified area) itself becomes APDU buffer for simultaneous command512.

While APDU buffer 508 that stores APDU issuance commands from externaldevice 150 is permanent as a fixed area, APDU buffer for simultaneouscommand 512 occupies the area in which APDU issuance commands are stored(specified area) only the moment a certain APDU issuance command isprocessed, and the address and size of the area vary momentarily everytime the next APDU issuance command is processed. That is, after firstAPDU issuance command (1-a) 525-1 is processed, the area occupied bynext APDU issuance command (2-a) 525-2 itself becomes APDU buffer forsimultaneous command 512.

Here, FIG. 8 that illustrates simultaneous command 160 in Embodiment 1will be compared with FIG. 27 that illustrates simultaneous command 520in this embodiment.

In FIG. 8, a LOAD command is divided into issuance command 2 to issuancecommand m. For example, when data to be downloaded is 2000 kbytes, ifthe maximum length of data that can be sent at a time, that is, datathat can be stored in APDU buffer 508 is assumed to be 255 bytes (thisapplies to plain text. And the maximum length of data (plain text)becomes shorter in the case of encryption or MAC assignment), since255×7<2000<255×8 and the data needs to be sent divided into 8 commands,the number of issuance commands m becomes m=9.

On the other hand, in FIG. 27, a Load command is specified by APDUbuffer for simultaneous command 512 and the command can thereby becompleted through only one-time processing. That is, out of thesimultaneous command, APDU buffer for simultaneous command 512 is alwaysonly an APDU issuance command which is about to be processed (specifiedarea) and direct reference section 510 refers to the area specified bythis APDU buffer for simultaneous command 512 and processes the area,and then only the next APDU issuance command to be processed (specifiedarea) becomes APDU buffer for simultaneous command 512.

The function of managing downloading of card management section 502(card manager) acquires data from APDU buffer for simultaneous command512 through direct reference section 510. This scheme is just the sameas card manager acquires data from APDU buffer 508 of card managementsection 502. In any case, the behavior of the card manager opereatesequivalent processing in terms of accessing the APDU buffer.

Next, the operation of the card manager will be explained in acomparison between the case where Load commands are received over aplurality of times as in the case of Embodiment 1 and the case whereLoad commands are received at one time as in this embodiment.

Processing Load commands over a plurality of times requires the numberof APDU issuance commands, processing of receiving APDU issuancecommands, processing of acquiring data from the APDU buffer, commandcheck to determine whether or not the commands are sent in correct orderor whether or not the command is the last one, data processing,retention of an intermediate state to process the next APDU issuancecommand and response sending processing.

On the other hand, processing Load commands at one time provides anadvantage that most of the above described series of processing becomesunnecessary.

Examples of timing of using direct reference section 510 include timingof requesting from card management section 502 to direct referencesection 510 after receiving a self-issuance start command and timing ofrequesting direct reference section 510 after card issuance section 504receives a self-issuance trigger.

As in the case of Embodiment 2 or Embodiment 3, it is possible to allowa privileged mode to be set in the secure device and use directreference section 510 only for a period during which the privileged modeis set.

Thus, according to this embodiment, through the direct referencesection, it is possible to drastically reduce routines compared with acase where APDU issuance commands are divided and processed, and omitredundant preparation to process the next APDU issuance command.Therefore, it is possible to drastically enhance the speed compared witha conventional technique of downloading APDU issuance commands from theexternal device over a plurality of times.

When an application is downloaded to the secure device using a highlyportable mobile terminal such as a cellular phone having a read/writefunction, the speed enhancement of card issuance is significant becausethe battery capacity which serves as a power supply is generallylimited.

Furthermore, in the case where the secure device is a removal mediumwhich can be inserted/removed into/from a cellular phone, the user maysuddenly switch off power or pull out the secure device while downloadis in progress. This causes a power supply halting to the secure device.The capability of high-speed processing in such cases also means thatthe possibility of being influenced by a user's wrong operation isreduced, which is therefore of great significance.

EMBODIMENT 6

FIG. 28 is a block diagram showing the configuration of a secure deviceaccording to Embodiment 6 of the present invention. The same componentsas those in the secure device according to Embodiment 1 are assigned thesame reference numerals and explanations thereof will be omitted.

When power supply to the card is cut in mid-flow of self-issuance, thesecure device stops card issuance and it is not possible to send aresponse to the external device. Therefore, the external device cannotknow the progress status of card issuance at the secure device.According to this embodiment, power supply is cut in even such a case,it is possible to identify an APDU issuance command whose card issuanceis stopped or an APDU issuance command close to this, and restart cardissuance from the identified APDU issuance command.

Comparing with the configuration of the secure device in FIG. 5, in FIG.28, secure device 600 adopts a configuration having card managementsection 602 and card issuance section 604 instead of card managementsection 102 and card issuance section 104.

Card management section 602 is provided with interruption historysending section 606 that stores a history of self-issuance interruptionsfor reasons of power interruption or the like by monitoring the numberof preceding commands indicating the number of APDU issuance commandsprocessed during self-issuance.

In addition to the function of card management section 102, cardmanagement section 602 has a function of storing a history ofself-issuance interruptions for reasons such as power interruption andoutputting the history to recovery section 608 of card issuance section604. As shown above, the history of self-issuance interruptions isstored by monitoring the number of preceding commands, and therefore itis possible to identify a first APDU issuance command that failed tosend a processing result to external device 150 due to an interruptionfrom the history of self-issuance interruptions.

Card issuance section 604 is provided with recovery section 608 thatidentifies an APDU issuance command to be restarted in self-issuancefrom the history of self-issuance interruptions input from interruptionhistory sending section 606.

In addition to the function of card issuance section 104, card issuancesection 604 has a function of identifying an APDU issuance command whoseself-issuance should be restarted when self-issuance is interrupted forreasons of power interruption or the like and self-issuance is thenrestarted and restarting the processing from the APDU issuance command.

The operation of secure device 600 configured as described above will beexplained using a flow chart in FIG. 29.

FIG. 29 is a flow chart showing the operation of the secure deviceaccording to Embodiment 6 of the present invention. In the example inFIG. 29, suppose the power to secure device 600 is cut duringself-issuance, self-issuance is interrupted and then power to the securedevice 600 is turned on again.

First, in step S8000, the power to secure device 600 is cut duringself-issuance. When a power interruption is detected, card managementsection 602 stores the history of self-issuance interruptions. Thehistory of self-issuance interruptions includes information capable ofidentifying the first APDU issuance command that failed to send theprocessing result to external device 150 due to the interruption out ofthe responses indicating the processing results of the APDU issuancecommands. Power interruption is detected using, for example, sessiontime out.

In step S8100, the interrupted power to secure device 600 is turned onagain.

In step S8200, card management section 602 receives a self-issuancestart command from external device 150.

In step S8300, card management section 602 decides whether or not thenumber of preceding commands managed by card management section 602 iszero. When the decision result shows that the number of precedingcommands is zero (S8300: YES), card management section 602 moves to stepS8400 and when the decision result shows that the number of precedingcommands is not zero (S8300: NO), it moves to step S8500. As shownabove, the number of preceding commands indicates the number of APDUissuance commands successfully processed. Therefore, that the number ofpreceding commands is not zero when power is turned on again means thatself-issuance of secure device 600 is interrupted when power isinterrupted in step S8000.

In step S8400, self-issuance similar to that in Embodiment 1 is startedby carrying out processing starting with the first APDU issuancecommand.

On the other hand, in step S8500, card management section 602 sends thehistory of self-issuance interruptions stored in interruption historysending section 606 to recovery section 608 of card issuance section604.

In step S8600, recovery section 608 of card issuance section 604identifies the reading out position of an APDU issuance command subjectto first processing to restart self-issuance.

Here, the identification processing on the APDU issuance command subjectto the first processing by recovery section 608 will be explained usingFIG. 30 and FIG. 31.

FIG. 30 illustrates an example of simultaneous command 610 according toEmbodiment 6 of the present invention.

Simultaneous command 610 in FIG. 30 corresponds to the configuration ofsimultaneous command 160 in FIG. 8 further provided with recoveryinformation 620. The rest of the configuration is identical to that ofsimultaneous command 160 in FIG. 8, and therefore explanations thereofwill be omitted.

FIG. 31 illustrates an example of the configuration of recoveryinformation 620 included in the simultaneous command in FIG. 30.

In FIG. 31, recovery information 620 is made up of recovery informationlength 630 indicating the length of recovery information 620, commandnumbers 640-1, 640-2, 640-m and offsets 650-1, 650-2, . . . , 650-m.Command numbers and offsets are set in a plurality of pairs.

Command numbers 640-1 to 640-m are information indicating an APDUissuance command from which processing is started when self-issuance isrestarted. Offsets 650-1 to 650-m are information indicating from whichposition of simultaneous command 610, APDU issuance commands identifiedby command numbers 640-1 to 640-m start.

Recovery section 608 can identify the command number of an APDU issuancecommand to be processed first to restart self-issuance with reference tothe history of self-issuance interruptions from card management section602. Recovery section 608 identifies the physical reading out positionof the APDU issuance command to be processed first out of simultaneouscommand 610 using above described recovery information 620.

Here, it has been assumed that the reading out position of the APDUissuance command is determined with reference to recovery information620, but it is also possible to identify the reading out position byanalyzing simultaneous command 160 with no recovery information 620 asshown in FIG. 8 from the beginning. For example, in FIG. 8, when thenumber of preceding commands is 2, it is possible to identify theaddress at which command length 170-1 exists, add the specified lengthto the address, then identify the address at which command length 170-2exists and determine the reading out position of APDU issuance command165-2 that follows.

In step S8700, processing is started from the APDU issuance commandidentified in step S8600 and self-issuance is started.

A case has been described above where the recovery processing shown inFIG. 29 can be redone from an APDU issuance command with which a powerinterruption occurred, maintaining the area secured and data stored sofar (a case where recovery processing is possible in command units).

In addition to this, the recovery processing may possibly include thefollowing pattern which is dependent on the mounting of the securedevice.

First, there can be a case where when power is turned on again or when aself-issuance request is received from an external device after a powerinterruption occurs, all the data processed in the secure device by thetime power interruption occur (secured area and stored data) is cleared.

The recovery processing in this case is to restart card issuance fromthe beginning. For the secure device to which such mounting is applied,it is possible to store the number of preceding commands to be managedby the card management section in a primary storage area such as RAM.Furthermore, the external device may also send a self-issuance commandwhen card issuance is requested from the user after a power interruptionoccurs.

Second, there may also be a case where the recovery processing can beredone after the certain APDU issuance command, maintaining dataprocessed in the secure device (secured area and stored data) beforeprocessing of a certain APDU issuance command (when recovery processingis possible in function units).

The recovery processing in this case is to store the APDU issuancecommand successfully processed in function units and restart processingfrom the next APDU issuance command. Therefore, there may also be a casewhere it is necessary to process the APDU issuance command successfullyprocessed when self-issuance is interrupted, but it is preferable fromthe standpoint of processing of card issuance.

A specific example where recovery processing is performed in functionunits will be shown below.

For example, suppose “1” is set in command number 1 (640-1) and “2” isset in command number (640-2) respectively in FIG. 31.

In FIG. 30, issuance command 3 (Load2) 165-3 is the third APDU issuancecommand and if a power interruption occurs while this issuance commandis being executed, the number of preceding commands managed by cardmanagement section 102 is “3” and is stored in a non-volatile storagearea such as EEPROM.

In this case, in step S8600 of FIG. 29, recovery section 806 to whichthe number of preceding commands “3” is input compares the number ofpreceding commands “3,” “1” which is set in command number 1 (640-1) and“2” which is set in command number (640-2), and since these have arelation of 1<2<3, recovery section 608 decides to restart the executionof the issuance command of “2” which is smaller than “3” and closest to“3.”

Card issuance section 604 then extracts issuance command 2 (Load1) 165-2corresponding to command number “2,” copies it to the APDU buffer andstarts card issuance.

This embodiment has described the case where it is decided whether ornot a command issued is zero at timing at which a self-issuance startcommand is received and self-issuance is restarted, but the presentinvention is not limited to this. For example, it is also possible todecide whether or not a command issued is zero when an interruption ofself-issuance ends (e.g.: when power is turned on again) and restartself-issuance.

Thus, according to this embodiment, even when self-issuance isinterrupted for reasons such as a power interruption of the securedevice, the secure device stores the history of interruptions, andtherefore it is possible to identify the optimal reading out position ofan APDU issuance command when self-issuance is restarted.

That is, since the card management section is provided with theinterruption history sending section and the card issuance section isprovided with the recovery section, it is possible to make a retry inpost-processing when power supply to the card is interrupted in mid-flowof self-issuance. Furthermore, the external device can make a retrywithout being aware of the progress status of self-issuance when powersupply to the secure device is restarted so that it is possible toreduce the load of card issuance.

As explained in the above embodiments, with regard to the secure deviceand external device of the present invention, the external device sendsan instruction to the secure device once and then the secure device canexecute processing independently, and therefore the present invention issuitable for card issuance in an insufficient condition of communicationwith the card or when the user freely executes card issuance using theuser's personal portable terminal device.

The present application is based on Japanese Patent Application No.2005-003596 filed on Jan. 11, 2005, the entire content of which isexpressly incorporated by reference herein.

INDUSTRIAL APPLICABILITY

The secure device of the present invention has effects of reducinginfluences by interruptions of communication with an external device andallowing a user to speedily and safely incorporate a desired applicationprogram and is suitable for use as a secure device that carries out cardissuance processing under instructions from the external device withwhich the secure device is connected and communicating.

1. A secure device comprising: a card issuance section that extracts acard issuance command corresponding to a function of a card to beacquired from command groups stored in an internal memory; and a cardmanagement section that executes the card issuance command extracted bysaid card issuance section.
 2. The secure device according to claim 1,wherein the command group is written by direct access from an externaldevice to the internal memory.
 3. The secure device according to claim1, wherein said card management section starts to execute the cardissuance command based on a request from an external device and sends aresponse indicating whether or not the card issuance has been successfulto the external device.
 4. The secure device according to claim 1,further comprising a privileged mode management section that sets aprivileged mode which prevents communication between said cardmanagement section and an external device, wherein said privileged modemanagement section sets the privileged mode at timing at which executionof the card issuance command is started.
 5. The secure device accordingto claim 4, wherein said card issuance section decides whether or notall card issuance commands have been executed successfully at said cardmanagement section, outputs a privileged mode cancellation request tosaid privileged mode management section when said card issuance sectiondecides that all card issuance commands have been executed successfullyor decides that some card issuance commands have not been executedsuccessfully, and said privileged mode management section cancels theprivileged mode when the privileged mode cancellation request is inputfrom said card issuance section.
 6. The secure device according to claim3, wherein said card issuance section monitors whether or not each cardissuance command has been executed successfully at said card managementsection and outputs, when some card issuance commands have not beenexecuted successfully, information to identify card issuance commandsthat have been executed successfully to said card management section,and said card management section sends a response including informationindicating that some card issuance commands have not been executedsuccessfully and identifying the card issuance commands that have beenexecuted successfully to the external device.
 7. The secure deviceaccording to claim 1, wherein said card issuance section comprises adirect reference section that directly refers to the command groupsstored in the internal memory, and said card management section executesthe card issuance command through the direct reference section.
 8. Thesecure device according to claim 3, wherein said card management sectionstores an interruption history in executing the card issuance command,reports a first card issuance command which has not sent any response tothe external device to said card issuance section, and said cardissuance section identifies a card issuance command to be executed firstfrom the interruption history and the first card issuance command whichhas not sent any response to the external device and restarts executionof the card issuance command.
 9. The secure device according to claim 1,wherein said card management section comprises a file management tableto identify a file for storing a plurality of command groupscorresponding to a plurality of card functions stored in the internalmemory and executes a card issuance command which relates to a commandgroup stored in a file specified by the external device.
 10. An IC cardissuance system comprising a secure device and an external device thatcommunicates with the secure device, wherein said external devicecomprises a command generation section that generates a request commandfor requesting card issuance and a command sending section that sendsthe request command generated to said secure device, and said securedevice comprises a card issuance section that extracts a card issuancecommand corresponding to a function of a card to be acquired fromcommand groups stored in an internal memory and a card managementsection that executes, when the request command is input, the cardissuance command extracted by said card issuance section.
 11. The ICcard issuance system according to claim 10, wherein said card managementsection of said secure device sends a response indicating whether or notthe card issuance has been successful to said external device, and saidexternal device comprises a response reception section that receives theresponse and a self-issuance management section that analyzes theresponse, ends card issuance when the response indicates that cardissuance has been successful and outputs an instruction for resendingthe request command to said command generation section when the responsedoes not indicate that card issuance has been successful.
 12. The ICcard issuance system according to claim 11, wherein said card issuancesection of said secure device monitors whether or not each card issuancecommand has been executed successfully at said card management sectionand outputs, when some card issuance commands have not been executedsuccessfully, information to identify card issuance commands that havebeen executed successfully to said card management section, said cardmanagement section of said secure device sends a response includinginformation indicating that some card issuance commands have not beenexecuted successfully and identifying the card issuance commands thathave been executed successfully to said external device, and saidself-issuance management section of said external device analyzes theresponse and outputs an instruction for sending a request command forstarting card issuance by executing the card issuance commands that havenot been executed successfully to said command generation section.